Version 3.3 fixes a number of bugs reported recently, which means that new bugs may appear – do not forget to make a reasonable backup before upgrading. Of course, please report a problem if you find one.
You may find helpful to review the list of Former Known Issues Resolved and the list of Known Issues still existing.
There is a couple of new options
A detailed Changelog is available at WordPress site and it will not be repeated here. A few new options worth of mentioning are listed below:
- Option “Highlight Style” – controls how translatable multilingual fields are styled to be distinctive from all the other normal fields. It is not important for simple sites, where only title and content are translatable, but when there are many integrated plugins, together with customization through options “Custom Fields”, it may become quite confusing to know which field is translatable and which is not. This option allows to visualize each translatable field. There are two different styles provided out of the box, and there is a way to put in your own custom CSS to highlight translatable fields any way you wish. This option is expected to be loved by the majority of users, while there is also a way to turn highlighting off at global site level, or per user choice. The original implementation of highlighting belongs to Michel Weimerskirch, whose contribution is appreciated very much.
- Option “LSB Style” – controls how Language Switching Buttons (LSB) are displayed. There is a couple of presets, as well as a way to provide your own CSS.
- Choice “Single Language Mode” for option “Editor Mode” – provides unbounded compatibility with other plugins and themes. There are no LSB in this mode, and the edit language is the same as admin one. You have to change admin language, if you wish to edit content in other languages. This mode introduces certain inconvenience, which is supposed to be outweighed by the compatibility benefits, if compatibility issue is a problem for a particular plugin and theme set. However, this essentially works the same way as normal LSB in case a user consciously decides not to switch the edit language during one editing session. This is why the advanced users may still use the default LSB mode, while taking special care of translatable fields at trouble. If you do not switch edit language during a session of editing of incompatible translatable field, then after pressing “Update” button your changes will be saved. If you switch language with LSB after editing an incompatible field and before pressing “Update” button, the changes may be lost. Conscious not switching the edit language on certain fields allows you to still use LSB mode, which bring convenience back for all other well-behaving fields.
- Option “Post Types” – to disable translation of certain custom post types.
Points to get confused about
- If you use plugin QTranslate Slug, expect some things do not work as expected, although it may appear working most of the time. When something is wrong, try turning QTranslate Slug off, before reporting the problem.
- Japanese predefined locale has changed to ‘ja_JP’, which may cause to disable language after update. Please, enable it again.
- The logic of using the list of languages on configuration page ‘/options-general.php?page=qtranslate-x’ is changed. All languages are now always shown, but only edited ones are stored in the database.
What to expect in the future releases
The next version will be dedicated to finalizing the 3rd-party integration interface. Your comments and suggestions are very welcome. Once the interface is finalized we will keep supporting it and encourage the 3rd-party developers to use the designated interface functions only, avoiding direct access of internal variables, as they are always a subject to be re-designed.
One the next versions will hopefully be dedicated to recovering functionality of QTranslate Slug in a native for qTranslate-X way.
Technical details
Below are technical details, which you may choose not to read at this time, since it will not affect the way you work.
The major new enhancement from technical point of view is how the translatable fields are implemented. You have probably learned in the past how qTranslate used to deal with multilingual fields. Java script of qTranslate would create a hidden copy of each translatable field, where multilingual content is stored, and rename the original field to make it temporary hold a single language text, which user can modify. When LSB is pressed, the single-language content is combined with other languages texts and stored in multilingual hidden field, while other language text is copied back to the original single-language field. Operation of copying texts back and forth would also happen on blur event, to update multilingual hidden field with a new content of edited single-language text. When “Update” button is pressed the content of hidden multilingual field is sent to the server. The original, renamed field, with the last edited single language text gets lost.
This way of working has trouble when blur event is not fired on time for whatever reason, or when a custom plugin makes use of the original field name and gets confused when it is renamed. These two are major reasons for incompatibility problems.
The new way of working implemented in version 3.3 no longer does renaming of the fields and no longer depends on blur event. Here is what happens:
- Java script of qTranslate-X now creates an additional hidden fields for each language and each translatable field, while the original field remains untouched.
- On page load, the multilingual content of the original filed gets distributed between the hidden fields according to the language, and the content of original field is replaced with the content of active edit language.
- When LSB is pressed, content of hidden fields get copied back and forth to the original field to switch the language appropriately. If no LSB button is pressed during editing session, the original field keeps single language loaded at the time of page load.
- When “Update” button is pressed, all the fields, original and all its language satellites are sent to a server and re-combining of multilingual content happens at the server side. The content of last edited field is used for the last active edit language, which makes it impossible to lose last modification.
In this way, qTranslate-X has no opportunity to break anything when other plugin or theme alters a translatable field content in a special non-standard way. This way makes it possible to implement “Single Language Editor Mode”, in which nothing special happens to translatable fields and compatibility issue becomes irrelevant.
Some advanced editing plugins like “Visual Composer” of any kind, for example, make a copy of the original translatable field to run their own way of editing. When editing is done they copy the relevant content back to the original field. For qTranslate-X, there is no way to know about such customization in a general way, which frequently makes two plugins incompatible.
To simplify the integration, qTranslate-X now provides a few Java script functions, including ‘addLanguageSwitchBeforeListener’ and ‘addLanguageSwitchAfterListener’, for example, which enables plugins to do their custom actions on language switch action. Unless an advanced plugin is integrated, it will most likely not be incompatible with qTranslate-X. The good news is that you would not care about it, if “Single Language Editor Mode” is in use. The other good news is that a 3rd-party plugin author may enable compatibility easily enough, if one wishes to cooperate.
The integration interface is now being designed and will hopefully take its final shape in the next version. Please, let the conflicting plugin authors know that qTranslate -X is ready to cooperate with them to tune the easiest possible way of general integration.
Please, enjoy the new features of version 3.3, and do not hesitate to report a problem, if you encounter one.
qTranslate-X explained 